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ABSTRACT 

This  paper  describes  a  field  demonstration  and  presents 
the  network  performance  of  an  802.11  ground-UAV 
network  composed  of  11  ground  stations,  a  mobile  vehicle 
and  two  fixed  wing  UAVs,  connected  by  two  routing 
gateways  to  a  legacy  wired  network.  The  network  effects 
demonstrated  include  mobility,  network  partitions, 
network  merges  and  gateway  failovers.  The  paper  presents 
experimental  results  for  recorded  data  traffic  and  for  the 
state  of  the  routing  protocols,  with  the  mobile  nodes 
participating  as  sources  of  data  traffic. 

I.  INTRODUCTION 

Under  the  Robust  Airborne  Networking  Extension 
(RANGE)  research  project,  sponsored  by  the  Office  of 
Naval  Research  (ONR),  Boeing  Research  &  Technology 
and  the  Naval  Research  Laboratory  (NRL)  developed, 
tested,  evaluated,  and  demonstrated  protocols  and 
techniques  for  resilient  mobile  internetworking  of 
unmanned  airborne  vehicles  (UAVs)  and  surface  nodes  to 
extend  surveillance  range  and  battlespace  connectivity. 
Some  of  the  advances  in  this  program  include: 

•  CONOPS:  We  developed  and  tested  with  new 
hybrid  air/surface  scenarios,  rather  than  purely 
surface-based  or  airborne  scenarios,  and  described 
operational  view  scenarios  in  terms  of  networking 
configurations. 

•  Unicast  Routing:  We  focused  on  how  to 
interconnect  mobile  ad  hoc  networking  (MANET) 
routing  domains  with  legacy  routing  domains, 
including  how  to  exploit  multiple  routing 
gateways  that  efficiently  survive  network  partition 
events  [Milcom  07a]. 

•  Multicast  Routing:  We  extended  our  unicast 
work  to  allow  for  integration  of  multicast  routing 
domains  in  the  MANET  with  upstream  legacy 
multicast  routing  domains,  again  in  a  manner  that 
supports  multiple  gateways  and  survives  partitions 
[Milcom  07b,  Milcom  08]. 


•  Implementations:  We  developed  new  or  extended 
existing  open  source  implementations  of  open 
standard  unicast  and  multicast  MANET  routing 
protocols,  and  showed  how  they  could  be 
integrated  with  legacy  protocol  implementations 
on  a  small  form-factor  ruggedized  mobile  router. 

This  paper  reports  on  a  field  demonstration  conducted  in 
April  2009  at  NASA  Dryden  Flight  Research  Center  on 
Edwards  AFB.  The  demonstration  was  conducted  by 
Boeing  Research  &  Technology  with  support  from  NRL, 
the  University  of  Illinois,  Urbana-Champaign,  and 
Boeing’s  Global  Military  Aircraft  division  based  in 
Palmdale,  CA.  We  deployed  a  surface  (ground)  network 
of  eleven  nodes,  and  flew  two  small  fixed-wing  UAVs 
above  this  deployed  site,  both  individually  and 
simultaneously.  Both  planes  were  equipped  with  Boeing’s 
miniaturized  mobile  routers  and  commodity  video 
cameras.  We  also  placed  a  mobile  router  on  a  ground 
vehicle  that  drove  around  the  site  and  sent  audio  and  video 
back  to  a  viewing  area.  The  demonstration  was  conducted 
successfully  and  was  observed  by  a  number  of  technical 
and  program  representatives  from  ONR,  NRL,  SPAWAR 
SSC-PAC,  AFRL,  and  Boeing. 

Although  this  event  was  primarily  a  field  demonstration 
and  not  a  scientific  experiment,  we  did  log  a  large  amount 
of  data  as  we  performed  experiments,  dry  runs,  a  rehearsal 
demo  and  the  actual  demo,  and  this  paper  summarizes 
some  of  the  data  gathered. 

The  paper  is  organized  as  follows:  We  first  review  the 
demonstration  goals  and  objectives,  and  then  describe  the 
layout  and  equipment  used.  The  remainder  of  the  paper 
describes  and  discusses  a  subset  of  the  data  gathered,  and 
we  summarize  with  some  topics  for  further  study. 

II.  DEMONSTRATION  GOALS 

As  noted  above,  the  RANGE  project  focused  on  the 
application  of  mobile  ad  hoc  networking  protocols  to 
airborne  and  hybrid  airborne/surface  scenarios,  and  our 
demonstration  vignettes  were  constructed  to  show  the 
protocol  features  developed  or  extended  in  the  program. 
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As  an  example,  we  considered  a  use  case  of  two  UAVs 
supporting  a  surface  network  consisting  of  largely  static 
nodes.  The  UAVs  served  as  a  source  of  data  and  also 
could  be  considered  as  advantaged  nodes  in  the  topology. 
The  hybrid  air/surface  network  was  interconnected  by  two 
gateways  to  a  notional  backbone  network  running  legacy 
protocols  and  devices.  A  key  element  of  the  RANGE 
project  was  to  show  how  such  MANETs  could  be 
interconnected  to  backbone  networks  in  the  non-trivial 
case  of  using  multiple  gateways  between  the  backbone  and 
the  MANET.  These  protocol  features  are  described  in 
more  detail  in  the  papers  referenced  in  the  Introduction. 

Accordingly,  we  laid  out  a  topology  of  1 1  MANET  routers 
on  the  field  (at  NASA  DFRC  lakebed)  and  complemented 
them  with  one  surface  and  two  airborne  mobile  routers. 
The  MANET  routing  domain  was  connected  to  the 
backbone  through  two  border  routers  that  had  instances  of 
both  MANET  and  legacy  protocols  running  on  different 
interfaces.  Figure  1  illustrates  the  basic  topology  used  for 
the  demonstration,  and  is  described  in  more  detail  in  the 
following  sections. 


HARDWARE 

The  two  fixed-wing  UAVs  (Figure  2)  are  %  scale 
Extra300s  airplanes  with  a  2  meter  wingspan.  A  dedicated 
nickel-metal  hydride  battery  powers  the  electronic  ignition 
for  the  Brilleli  46  GT  gasoline  engine.  Onboard  the  plane 
are  a  GPS  antenna,  900  MHz  (0.1  Watt)  communications 
antenna,  a  number  of  lithium  polymer  batteries  for  system 
power,  and  a  Piccolo  Plus  autopilot.  They  are  owned  and 
maintained  by  Aerospace  Laboratory  for  Embedded 
Autonomous  Systems  (ALEAS)  of  the  University  of 
Illinois  at  Urbana-Champaign  [UIUC]. 

The  UAV  has  a  payload  capacity  of  roughly  5  lb,  and  a 
flight  time  of  15-30  minutes.  A  payload  bay  with 
dimensions  of  4”x  5.75”x  6.25”  is  available  to  house  a 
Boeing  mobile  router. 


Two  modifications  have  been  made  to  the  UIUC  UAVs  to 
support  the  RANGE  demonstration.  First,  a  small  hole  has 
been  cut  in  the  bottom  of  the  fuselage  to  mount  a  small 
USB-based  video  camera,  which  is  connected  to  the 
Boeing  mobile  router.  Second,  a  hole  has  been  cut  to  allow 
the  protrusion  of  a  small  rubber  dipole  antenna  for  the 
mobile  router’s  802.1 1  radio. 


Figure  2:  UA  V 


For  the  airborne  platform,  we  selected  a  ruggedized 
PC/104  based,  400MHz  computer  from  Parvus  as  our 
mobile  router  platform.  Packed  together  with  a  MiniPCI 
adapter,  a  802.11  card,  a  power  board  and  a  GPS  board,  it 
fits  into  an  aluminum  railed  card  cage  (also  from  Parvus), 
that  fits  into  a  cube  of  4”  on  each  dimension.  We  also 
added  rubber  shock  absorbers  (Shock  Rocks  from  Parvus) 
that  attach  to  the  comers  of  the  cube,  adding  about  0.5”  in 
each  direction,  as  seen  in  Figure  3.  The  entire  hardware  is 
about  2.5  pounds  without  the  battery.  We  used  the  battery 
already  on  the  plane,  the  power  board  allowing  any  input 
between  8  and  40Vdc;  the  computer  consumes  about  10W. 
Ground  nodes  had  similar  specifications,  however  they 
were  not  mggedized. 

We  used  commercial  802.11b  radios  and  antennas.  The 
radio  model  was  an  EnGenius  EMP-8602  PLUS-S  dual¬ 
band  802.11  a/b/g  card  with  up  to  600  mW  of  transmit 
power.  During  the  demonstration,  nodes  were  set  on 
802.11b  mode,  5.5  Mbps  base  rate  for  both  unicast  and 
multicast,  at  either  600  mW  or  400  mW  transmit  power. 
The  antenna  was  a  7  dBi  Rubber  Duck  Omni  RP-SMA  for 
the  2.4  GHz  band.  Link  rate  adaptation  was  turned  off. 

All  mobile  routers  used  a  GlobalSat  BU-353  USB  GPS 
Receiver  based  on  the  SiRF  Star  III  High  Performance 
GPS  chipset.  We  used  the  built-in  patch  antenna  and  USB 
connector  to  the  router.  The  video  cameras  used  were 
Logictech  Quickcam  for  Notebooks  Pro,  and  the  video  rate 
was  set  to  400Kbps,  for  an  image  of  320x240  pixels, 
15fps. 


Figure  3:  Boeing  Mobile  Routers:  miniaturized  (airborne)  and 
standard  (ground)  versions 
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We  selected  the  Cisco  3845  Integrated  Services  Router  for 
the  backbone  topology  segment  of  our  field  demonstration 
configuration.  More  specifications  are  available  on  the 
web  [Cisco3845]. 

SOFTWARE 

Software  in  use  included  the  following: 

•  OSPF  MANET  software  with  extensions  developed 
under  the  RANGE  project  for  multi-gateway 
operation; 

•  PIM/SMF  gateways  for  multicast  integration; 

•  NRL’s  Scripted  Display  Tool  (SDT)  for  visualization 
of  node  position  and  routing  links; 

•  NRL’s  MGEN  traffic  generation  software,  including 
and  GPS  integration  through  gpsLogger; 

•  NORM,  RTP  and  VLC  for  video  transmission  and 
reception; 

•  iVoX  for  voice  transmission  and  reception; 

Open  Shortest  Path  First  (OSPF)  is  a  popular  routing 
protocol  for  wired  networks.  OSPF  MANET  is  an 
extension  of  OSPF  for  IPv6  [OSPFv3]  to  support  mobile 
ad  hoc  networks  (MANETs).  The  extension,  called  OSPF- 
MDR,  is  designed  as  a  new  OSPF  interface  type  for 
MANETs.  OSPF-MDR  is  based  on  the  selection  of  a 
subset  of  MANET  routers,  consisting  of  MANET 
Designated  Routers  (MDRs)  and  Backup  MDRs.  The 
MDRs  form  a  connected  dominating  set  (CDS),  and  the 
MDRs  and  Backup  MDRs  together  form  a  biconnected 
CDS  for  robustness  [OSPF -MANET]. 

Boeing  has  developed  an  implementation  of  OSPF 
MANET  as  an  extension  of  the  quagga  routing  suite.  Note 
that  while  OSPF  MANET  is  specified  for  IPv6,  extensions 
exist  to  carry  IPv4  routing  information  in  the  protocol.  All 
of  the  applications  in  this  demonstration  were  IPv4-based. 

Protocol  Independent  Multicast  -  Dense  Mode  (PIM- 

DM)  is  a  multicast  routing  protocol  that  uses  the 
underlying  unicast  routing  information  base  to  flood 
multicast  datagrams  to  all  multicast  routers.  Prune 
messages  are  used  to  prevent  future  messages  from 
propagating  to  routers  without  group  membership 
information  [PIM-DM].  Boeing  developed  a  PIM-DM 
software  implementation  as  an  extension  to  the  XORP 
routing  suite. 

Simplified  Multicast  Forwarding  (SMF)  is  a  mechanism 
that  provides  basic  IP  multicast  forwarding  suitable  for 
wireless  mesh  and  mobile  ad  hoc  network  (MANET)  use. 
SMF  specifies  techniques  for  multicast  duplicate  packet 
detection  (DPD)  to  assist  the  forwarding  process.  SMF 
also  specifies  DPD  maintenance  and  checking  operations 
for  both  IPv4  and  IPv6.  SMF  takes  advantage  of  reduced 
relay  sets  for  efficient  MANET  multicast  data  distribution 
within  a  mesh  topology  [SMF]. 

In  the  demonstration,  our  routing  software  integrated  a 
Boeing  PIM-DM  implementation  with  NRL’s  SMF 
software,  which  was  using  the  OSPF  MANET  CDS  for 


multicast  relay  set.  More  details  on  this  integration  are 
found  in  [Milcom08]. 


Figure  4:  SDT  display  of  the  deployed  surface  topology. 

The  Scripted  Display  Tool  (SDT)  is  open  source  software 
by  NRL’s  PROTEAN  Research  Group  that  provides  a 
simple  visualization  capability  using  standard  image  files 
for  a  background  and  set  of  overlayed  nodes.  A  custom 
coordinate  system  can  be  defined  for  the  background  -  in 
our  case,  the  GPS  coordinates  of  the  demonstration  area, 
as  show  in  Figure  4  -  and  node  positions  can  be 
dynamically  updated  to  ’’move”  their  associated  icons 
about  the  background  [SDT]. 

The  Multi-Generator  (MGEN)  is  open  source  software 
developed  by  the  NRL’sROTEAN  Research  Group. 
MGEN  provides  the  ability  to  perform  IP  network 
performance  tests  and  measurements  both  UDP  and  TCP. 
It  also  supports  the  inclusion  of  the  node's  current  GPS 
position  with  each  packet  sent  through  the  network,  as  well 
as  the  time  the  packet  was  sent  (for  latency 
measurements).  [MGEN]. 


Figure  5:  Trajectory  of  the  plane  that  streamed  video. 


The  NORM  protocol  and  software,  developed  at  NRL,  is 
designed  to  provide  end-to-end  reliable  transport  of  bulk 
data  objects  or  streams  over  generic  IP  multicast  or  unicast 
forwarding  services.  NORM  uses  a  selective,  negative 
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acknowledgement  (NACK)  mechanism  for  transport 
reliability  and  offers  additional  protocol  mechanisms  to 
conduct  reliable  multicast  sessions  with  limited  ”a  priori” 
coordination  among  senders  and  receivers.  A  congestion 
control  scheme  is  specified  to  allow  the  NORM  protocol 
fairly  share  available  network  bandwidth  with  other 
transport  protocols  such  as  Transmission  Control  Protocol 
(TCP).  It  is  capable  of  operating  with  both  reciprocal 
multicast  routing  among  senders  and  receivers  and  with 
asymmetric  connectivity  (possibly  a  unicast  return  path) 
from  the  senders  to  receivers.  The  protocol  offers  a 
number  of  features  to  allow  different  types  of  applications 
or  possibly  other  higher  level  transport  protocols  to  utilize 
its  service  in  different  ways.  NORM  leverages  the  use  of 
FEC-based  repair  and  other  IETF  reliable  multicast 
transport  (RMT)  building  blocks  in  its  design  [NORM]. 

NRL’s  I  VOX,  the  Interactive  VOice  exchange 
application,  is  a  Voice  over  IP  (VoIP)  application  that 
supports  unicast  and  multicast,  and  also  includes  NORM 
integration  for  reliable  communications.  IVOX  supports  a 
number  of  voice  encoding  algorithms  with  data  rates 
extending  from  as  low  as  600  bps. 

We  have  instrumented  our  mobile  routers  to  store  a  variety 
of  logs.  The  experiment  logging  and  data  collection 
framework  is  based  on  Python  and  shell  scripting.  It 
includes  sending  MGEN  beacons  (including  location 
information)  to  the  visualization  node;  logging  GPS 
information  (latitude,  longitude,  altitude,  and  time); 
logging  signal  strength  information  from  up  to  8  other 
wireless  peers  (the  iwspy  statistic  limit);  monitoring  kernel 
route  changes  using  rtmon;  saving  a  full  tcpdump  from 
each  specified  network  interface;  using  athstats  to  record 
wireless  statistics;  and  saving  the  output  of  quagga,  XORP, 
and  SMF  log  files.  Logging  can  be  configured  to  start 
automatically  at  boot  time,  or  at  the  time  of  acquiring  a 
GPS  fix. 

Scripts  have  been  developed  to  process  the  multicast 
experimental  results  to  generate  end-to-end  outage 
statistics  and  traffic  graphs  at  each  gateway. 

VISUALIZATION 

We  integrated  our  code  with  GPS  logging  and  NRL’s 
Scripted  Display  Tool  (SDT)  for  visualization  (Figure  4), 
used  a  Boeing  custom  traffic  trace  plotter  to  show  OSPF 
overhead,  and  used  the  Video  Lan  Client  (VLC)  for  video 
display. 

We  used  SDT  in  two  ways  during  the  demonstration.  The 
first  use  was  to  show  the  dynamic  OSPF  topology.  In 
figure  4,  the  geographic  layout  of  the  surface  nodes,  as 
well  as  links  between  them,  are  rendered  against  a  aerial 
photograph  of  the  lakebed.  We  modified  the  quagga 
OSPFv3  code  to  log  network  links  to  a  file  in  a  format 
compatible  with  NRL’s  CMAP  tool.  The  log  file  and 
update  interval  can  be  configured  using  a  quagga  vty 
command  either  interactively  or  from  a  configuration  file. 
Specifically,  nodes  were  color  coded  as  follows.  Purple 
nodes  were  active  OSPF  MANET  MDR  routers  that  were 


selected  as  MDR  forwarders  (also  SMF  forwarders  in  the 
multicast  topology).  Green  nodes  were  active  OSPF 
MANET  routers  that  were  not  MDRs.  Red  nodes  illustrate 
nodes  for  which  FPS  reporting  is  absent,  such  as  the  node 
152  (airplane  node)  in  the  screenshot  after  it  was  returned 
to  ground  and  powered  off.  The  red  lines  between  nodes 
displayed  the  links  advertised  by  OSPF  MDR  routers  in 
Router-LSAs.  Note  that  in  OSPF  MANET  MDR,  this  set 
of  links  does  not  represent  the  full  topology  but  instead 
represents  a  pruned  routing  topology  designed  to  give 
nearly  shortest  paths  without  the  need  to  report  all 
neighbor  adjacencies.  Therefore,  the  usable  RF  topology 
was  actually  greater  than  that  depicted  in  Figure  4.  In 
addition,  we  configured  another  display  of  SDT  to  show 
the  active  unicast  route  between  the  surface  mobile  router 
node  and  the  gateways. 

During  the  course  of  the  demonstration,  the  SDT  displays 
dynamically  updated  the  network  topology  display  as  node 
position  and  connectivity  changed.  When  the  planes  were 
airborne,  they  were  shown  as  fast  movers  against  the  rest 
of  the  network  on  the  map. 

We  captured  and  displayed  real-time  plots  of  the  OSPF 
traffic  both  in  the  MANET  and  in  the  backbone,  on  similar 
vertical  scales.  The  displays  illustrated  that  the  MANET 
routing  protocol  overhead  was  largely  contained  within  the 
MANET  routing  domain,  and  the  routes  redistributed  by 
the  gateway  nodes  did  not  contribute  much  to  the 
backbone  overhead.  DATA 


ANALYSIS 

We  extracted  the  packet  delivery  ratio  (excluding 
duplicates)  of  multicast  traffic  sent  from  a  flying  plane, 
received  at  a  host  computer  within  the  legacy  network 
sitting  behind  the  two  gateways  running  PIM-DM/SMF. 
As  the  plane  was  streaming  video  at  a  rate  of  400Kbps,  we 
sent  two  streams  of  multicast  traffic  in  parallel,  each  at  a 
rate  of  10  packets  per  second,  each  packet  carrying  a  100 
byte  payload.  One  of  the  streams  was  received  natively  at 
the  host  computer,  while  the  other  multicast  stream  was 
forwarded  through  the  NRL  NORM  implementation. 
NORM  was  configured  with  a  buffer  of  75KB  at  the 
sender,  (about  1.5  sec  of  video),  and  with  a  25%  FEC 
redundancy.  Figure  5  shows  the  trajectory  of  the  streaming 
plane  during  the  experiment.  We  divided  the  flight  test 
time  into  5  different  phases  defining  scenarios  that  were 
analyzed  independently. 

•  In  phase  1,  both  planes  were  in  the  air  (nodes  150  and 
152),  flying,  with  one  plane  sending  multicast  video 
and  data,  and  the  second  plane  forwarding 
opportunistically  depending  on  its  MDR  status. 
However,  in  this  experiment  we  observed  the  second 
plane  to  be  a  forwarder  (relay)  only  once,  for  a  short 
amount  of  time  (1.52  sec). 

•  In  phase  2  we  turned  off  the  router  carried  by  the 
second  plane  (node  150),  such  that  the  plane  streaming 
video  and  data  had  to  rely  only  on  the  ground  network 
for  forwarding. 
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Figure  6:  Multicast  loss  rate  during  the  flight  test. 


•  In  phase  3,  we  turned  off  the  gateway  used  for  data 
forwarding  between  SMF  and  PIM,  such  that  the 
multicast  routing  protocol  had  to  adjust  its  routing 
paths  and  fail  over  to  the  second  gateway. 

•  In  phase  4  we  started  turning  off  all  ground  node 
routers,  one  by  one,  until  all  of  them  were  off  except 
the  second  gateway. 

•  Finally,  in  phase  5  we  continued  to  monitor  the  data  as 
the  plane  could  only  connect  directly  to  the  second 
gateway,  as  all  other  ground  nodes  were  off. 

Figures  6a  and  6b  show  the  loss  rate  of  multicast  traffic 
without  and  with  NORM,  respectively,  in  phase  1,  when 
both  planes  were  in  the  air.  Each  bar  shows  the  loss  rate 
averaged  on  a  5  second  interval.  We  can  see  that  for  most 
of  the  time,  the  multicast  traffic  was  affected  by  moderate 
loss,  which  could  be  successfully  recovered  by  using 
NORM.  Several  instances  of  long  term  disconnections 
(lasting  a  few  seconds  each)  could  not  be  masked  by 
NORM  and  they  appear  also  in  Figure  6b.  Overall,  the 
average  loss  rate  for  the  entire  phase  was  24.64%  without 
using  NORM,  and  14.48%  using  norm. 

Figure  6c  shows  the  multicast  loss  rate  using  NORM 
during  phase  2,  when  only  one  plane  was  in  the  air.  The 
behavior  is  very  similar  to  having  two  planes  in  the  air, 
with  the  total  loss  rate  being  28.16%  for  direct  multicast, 
and  14.20%  for  NORM  multicast.  This  is  because,  in  this 
experiment,  during  the  entire  flight  of  the  second  plane,  its 
corresponding  router  has  been  selected  to  be  an  MDR  only 
for  1.52  seconds,  at  time  65.89  seconds  into  flight.  We  did 
not  bias  the  demonstration  to  preferentially  select  the  other 


airborne  node;  it  did  so  automatically  according  to  the 
protocol  heuristics. 

Figure  6d  shows  the  NORM  multicast  during  phase  3, 
when  the  default  gateway  has  been  turned  off.  We  can  see 
one  short  disconnection  period  as  the  protocol  had  to  fail 
over  to  the  second  gateway. 


OSPF  MDR  State 


-  one  plane  shuts  down 

-  -  •  one  gateway  shuts  down 
•  routers  shutting  down 

.  only  one  plane/gateway 


Figure  7:  MDR  status  of  the  network  nodes. 

As  we  were  shutting  down  more  nodes  in  the  ground 
network,  we  can  see  in  figure  6e  that  the  number  of 
disconnection  events  also  started  to  increase,  to  a 
significant  number  by  the  time  that  only  one  gateway  node 
was  still  running  in  phase  5,  as  shown  in  Figure  6f.  We 
also  plot  the  distance  between  the  plane  and  gateway  in 
Figure  6f,  quantified  on  the  vertical  axis,  because  the  plane 
had  to  be  directly  connected  to  the  gateway  in  order  to  be 
able  to  communicate  during  Phase  5. 
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Figure  8:  Trajectory  of  the  ground  mobile  node. 


It  is  interesting  to  note  the  MDR  status  of  different  nodes 
during  the  flight  test,  shown  in  Figure  7.  For  most  of  the 
time,  node  167  was  selected  as  a  MDR,  due  to  its  good 
connectivity  given  by  its  placement  in  the  network,  and 
also  due  to  its  high  id  number.  The  next  node  with  a  high 
ID  number,  and  also  well  connected,  node  166,  was  also 
selected  as  an  MDR  from  time  to  time;  other  nodes  were 
selected  as  MDRs  when  needed,  in  order  to  provide 
connectivity  to  the  plane  -  note  that  nodes  164  and  165 
were  placed  at  the  East  and  West  limits  of  the  network. 
Node  161,  the  second  gateway  and  the  only  node  left  up  in 
Phase  5  of  the  experiment  became  an  MDR  during  that 
phase,  as  expected.  However,  node  161  was  also  selected 
to  be  an  MDR  occasionally  during  the  previous  phases  of 
the  experiment,  which  makes  us  believe  that  its  radio 
connectivity  to  the  other  MDR  nodes,  167  and  166,  was 
not  very  stable,  even  though  the  nodes  was  relatively  close 
to  them. 

In  a  different  experiment,  instead  of  flying  planes 
according  to  a  preset  figure  eight  GPS  pattern,  we  were 
driving  a  mobile  node  (node  151)  on  a  jeep  randomly 
throughout  the  network,  as  shown  in  Figure  8,  which  plots 
the  recorded  GPS  position  of  the  mobile  node. 


Figure  9:  Link  status  for  the  ground  mobile  node 

For  this  experiment,  Figure  9  shows  the  status  of  neighbor 
links  for  the  ground  mobile  node.  We  can  see  that,  for 
most  of  the  time,  the  mobile  node  maintained  good 
connectivity  with  the  other  nodes,  its  links  being  in  either 


two  way  (blue)  or  full  (green),  and  maintained  its  full 
status  to  nodes  166  and  167,  which  were  best  positioned  in 
the  network  and  therefore  were  selected  as  MDR  or 
BMDR.  The  direct  link  with  node  161,  which  was  one  of 
the  gateways,  experienced  the  highest  rate  of  state 
changes,  indicating  a  poor  connectivity  for  node  161. 


Figure  10:  Percentage  of  time  OSPF  link  between 
nodes  166  and  167  was  in  two  way  or  fully  connected. 

During  the  entire  demonstration  we  noticed  a  high 
variability  of  the  wireless  link  quality  throughput  during 
the  day,  corresponding  with  changing  environmental 
conditions  (e.g.  wind  speed,  temperature).  In  the  morning, 
the  wireless  connectivity  was  in  general  good  and  the 
topology  was  fairly  stable.  As  the  day  progressed,  we 
noticed  a  general  degradation  of  the  wireless  channel 
quality,  at  times  rendering  the  network  topology 
completely  unstable.  For  a  day  of  experiments  with  the 
entire  topology  deployed  at  07:52:34  AM,  and  lasting  until 
01:03:35  PM,  during  which  the  ground  nodes  did  not 
move,  we  monitored  the  link  between  the  stationary  nodes 

166  and  167.  These  were,  initially,  reasonably  well 
connected,  and  due  to  their  position  in  the  network,  were 
selected  to  be  MDRs  most  of  the  time.  Figure  10  plots 
percentage  of  time  the  OSPF  link  between  nodes  166  and 

167  was  in  two  way  or  fully  connected,  averaged  over  15 
minute  intervals.  These  were  located  about  500  feet  apart, 
with  no  obstacles  between  them,  raised  at  about  3  feet 
from  the  ground.  We  can  see  that,  even  for  two  static 
nodes,  the  link  quality  varies  dramatically  between  24  to 
95%  up  during  the  day.  We  were  not  equipped  to  measure 
wind  speed,  but  we  anecdotally  observed  a  correlation 
between  increased  wind  speed  during  the  day,  and  reduced 
stability  of  the  network  topology.  We  suspect  this  may  be 
due  to  wind  kicking  up  dust  particles.  Even  a  small  amount 
of  dust  that  remains  near  the  ground  could  cause  problems 
for  the  wireless  signal,  particularly  given  the  low  antenna 
heights  of  the  fixed  ground  nodes. 
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SUMMARY 

This  demonstration  is  believed  to  be  the  first  airborne  field 
demonstration  that  combined  OSPF  MANET  and  NRL 
SMF  protocols  with  OSPFv2  and  PIM-DM  legacy 
protocols,  in  a  multiple  gateway  scenario  using  UAVs  in 
the  MANET.  While  the  ability  to  connect  MANET 
unicast  and  multicast  to  larger  legacy  networks  was 
proven,  several  unsolved  issues  remain  to  be  adressed: 

•  Even  when  the  links  in  the  network  are  predicted  to  be 
static,  there  is  a  fair  amount  of  variable  link 
performance.  We  introduced  some  heuristics  in  our 
OSPF  MANET  implementation  that  enabled  the  link 
cost  between  nodes  to  improve  (lower)  over  time, 
thereby  favoring  more  stable  links  for  path  selection. 
We  believe  that  similar  approaches  would  be 
beneficial  to  improve  the  MDR  selection  process  and 
stabilize  the  set  of  MDR  forwarders,  at  the  cost  of 
more  redundancy  in  the  MDR  set.  Improved  adaptivity 
of  MANET  protocols  is  a  focus  of  a  recently  started 
research  program  for  ONR. 

•  The  protocols  used  in  our  demonstration  were  based 
solely  on  in  band  network  discovery.  To  the  extent  that 
information  on  link  quality,  neighbors,  and  radio 
events  can  be  learned  out-of-band,  we  believe  that 
performance  will  also  improve. 
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